With the development of new technologies in mobile telecommunication networks, Operation and Management (O&M) of said technologies meets new challenges. The increasing complexity of the successive generations of mobile systems requires more detailed O&M functionality. As an example, in legacy Radio Access Network (RAN) Management Systems (MSs), such as for the Global System for Mobile Communications (GSM), the MSs have limited O&M functionality and provide only low resolution data, whereas in Long Term Evolution (LTE), for the RAN MSs, a large number of various high resolution data sets are provided in order to log events, keep track of operation status and localize potential problems.
FIG. 1 shows the principle of event logging. As shown in FIG. 1, a mobile telecommunication network 100 comprises a Network Management System (NMS) 1001 and network nodes 1002-1, 1002-2, . . . , 1002-n attached thereto. Each of the nodes 1002-1, 1002-2, . . . , 1002-n logs one or more events and increases related counters, and reports the same to the NMS 1001. The NMS 1001 may aggregate the received reports, and may also perform event logging and counting on its own, for example by probing the nodes 1002-1, 1002-2, . . . , 1002-n. 
Accordingly, the reported performance measurements are performed in the nodes 1002-1, 1002-2, . . . , 1002-n locally. There are basically two types of measurement reporting, one resides in typically periodic reports of counters, and the other one is event reporting (in the following, the different measurement types will be described). The NMS 1001 fetches these reports from the nodes 1002-1, 1002-2, . . . , 1002-n and stores them for a certain period of time.
Further, the existing technology for Performance Management (PM) used by the NMS 1001 or, alternatively, by an Operation Support System (OSS, not shown) of the mobile telecommunication network 100 provides tools for generating long-term statistics, time-series analysis and trend analysis for individual measured parameters. This may be achieved by regularly collecting PM counters reported in the nodes 1002-1, 1002-2, . . . , 1002-n at the end of a previously defined granularity period (also called Result Output Period, ROP, e.g., with a typical length of 15 minutes).
PM may also be based on more detailed measurement logs such as event logs to keep track of the operations on a finer timescale (such as seconds, milliseconds). The event logs can be used for troubleshooting and more detailed analysis. It is also possible in PM to collect event logs from various sources (e.g., from the multiple nodes 1002-1, 1002-2, . . . , 1002-n) in the network and combine (e.g., correlate) them, thus providing an end-to-end (E2E) PM functionality (such as an E2E fault localization). The events collected from the different nodes 1002-1, 1002-2, . . . , 1002-n and especially the correlated events have a large number of parameters concerning the measured values. This enables an operator to determine dependencies between Key Performance Indicators (KPIs) and parameters, and further facilitates root cause analysis of performance degradation.
The PM counters regularly collected in ROPs on a minute timescale provide a possibility to generate long-term statistics for the measured parameters separately. The event logs collected (and possibly correlated from multiple nodes 1002-1, 1002-2, . . . , 1002-n) usually on a (milli)second timescale allow for generating detailed short-term statistics and determining relations between different KPIs and parameters.
An exemplary concept for PM in the mobile telecommunication network 100 is standardized in 3rd Generation Partnership Project (3GPP) Technical Specification (TS) 32.401 V11.0.0, see Section 4. Furthermore, 3GPP provides particular performance measurement definitions, e.g., for GSM and later mobile communication networks. According to 3GPP, the generation of the performance measurement results may be performed by a Network Element (NE) (e.g., any of the nodes 1002-1, 1002-2, . . . , 1002-n) either by aggregating and calculating statistical information of events or by exposing internal variables (e.g., of the nodes 1002-1, 1002-2, . . . , 1002-n).
The performance measurement types can be classified into the following categories (as defined, e.g., in TS 32.401 V11.0.0, Section 4.2.2):                Cumulative counter: The NE maintains a running count of the event being counted. The counter is reset to a well-defined value (usually “0”) at the beginning of each granularity period.        Status inspection: The NE maintains internal counts for resource management purposes. These counts are read at a predetermined rate, and the rate is usually based upon the expected rate of change of the count value. Status inspection measurements may be reset at the beginning of the granularity period and will only have a valid result at the end of the granularity period.        Gauge: The so-called gauge represents dynamic variables that may change in either direction, e.g., in both directions on a number ray. Gauges can be integer valued or real valued. If a gauge is required to produce low and high tide marks for a granularity period (e.g., minimum and maximum call duration), then it may be reinitialized at the beginning of each granularity period. If a gauge is required to produce a consecutive readout over multiple granularity periods (e.g., cabinet temperature), then it may only be reinitialized at the start of a recording interval.        Discrete Event Registration (DER): Data related to a particular event are captured. Every n-th event is registered, where n can be 1 or larger. The value of n is dependent on the frequency of occurrence of the event being measured. DER measurements may be reset at the beginning of each granularity period and may only have a valid result at the end of the granularity period.        
It has been found that the existing performance measurement and reporting strategies, such as periodic reports and event logging, do not always satisfy O&M needs. For example, periodic reports in certain implementations hide the details of performance problems, while event logging is cumbersome in terms of storage and processing resources when performed over an extended period of time (e.g., months or years).